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(54) Methods and systems for authentication through multiple proxy servers 



(57) Methods, systems, computer program prod- 
ucts and data structures are described which allow a cli- 
ent to communicate with a server even though multiple 
proxies that require different authentication data must 
be traversed to allow such communication. In operation, 
the client first authenticates to a first proxy using authen- 



tication data appropriate for the first proxy. The client 
then authenticates to a second proxy using different au- 
thentication data that is appropriate for the second 
proxy. This proxy authentication continues through as 
many proxies as necessary until the client is in commu- 
nication with the server. 
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Description 

BACKGROUND OF THE INVENTION 

1 . The Field of the Invention 

[0001] The present invention relates to the field of 
electronic authentication. In particular, the present in- 
vention relates to methods and systems for authentica- 
tion through multiple proxy servers that require different 
authentication data such as user identification and pass- 
word. 

2. Background and Related Art 

[0002] A "proxy server" or "proxy" is a computer or 
computer system that acts as an intermediary between 
a client computer system (hereinafter, a "client") and a 
server computer system (hereinafter, a "server"). When 
a client-submits a request to a server, the proxy, through 
which the request must traverse, may require client au- 
thentication that is independent of the client authentica- 
tion required by the server. One typical way for a client 
(or a user thereof) to authenticate to the proxy is to pro- 
vide authentication data such as a user identification 
(ID) and password to the proxy. The client may also pro- 
vide a separate user ID and password to the server 
when authenticating to the server. 
[0003] The Internet standard HyperText Transport 
Protocol (HTTP) provides a transport level protocol for 
communicating between a client and server. Among oth- 
er things, HTTP provides for a means for authentication 
to a proxy even though that proxy requires different au- 
thentication data than the server. Conventional HTTP 
allows for a header field that may include a user ID and 
password for authenticating to the proxy. HTTP also al- 
lows for a separate header that may include a separate 
user ID and password for authenticating to the server. 
Even If HTTP requests from the client traverse multiple 
proxies that require authentication on the way to the 
server, so long as the proxies each require the same 
user ID and password (as is often the case when the 
multiple proxies are managed by the same entity), the 
header that includes the password for the proxy may be 
used to authenticate to each proxy. Thus, conventional 
methods allow HTTP to be used to authenticate to a sin- 
gle proxy (or to multiple proxies that require the same 
user ID and password) and to a server. 
[0004] These conventional methods have some ad- 
vantages, including allowing for authentication to multi- 
ple proxies within a single administrative domain, all of 
which use the same credentials. However, these con- 
ventional methods do not allow for authentication 
through multiple proxies if those proxies require different 
authentication data as compared to each other. 
[0005] Often, proxies that reside within a common 
sphere of trust may use the same user ID and password 
when authenticating a particular user. For example, 



proxies that are managed by the same entity may often 
use the same user ID and password to authenticate a 
particular user. However, ft may be desirable to allow 
proxies between the client and server to user different 

5 authentication data when authenticating the user of the 
client. For example, suppose that the client is a wireless 
device and the server is a corporate server. The wireless 
device may communicate through a proxy managed by 
the wireless service as well as a proxy managed by the 

10 corporation that hosts the corporate server. The wire- 
less service and the corporate server may not trust each 
other so far as to share a common user ID and password 
for a given user. 

[0006] Therefore, what is desired are systems and 
is methods for authentication through multiple proxies 
even though those multiple proxies may require different 
user IDs and passwords when authenticating. It would 
further be desirable if such authentication could be done 
so that each proxy may only access the authentication 
20 data relevant for authentication to that particular proxy, 
and not be able to access different authentication data 
intended for other proxies. It would also be desirable if 
such authentication could be done without modification 
of existing protocols and standards. 

25 

SUMMARY OF THE INVENTION 

[0007] Methods, systems, computer program prod- 
ucts and data structures are described which overcome 

30 the foregoing problems with the state of the art. Specif- 
ically, the principles of the present invention enable a 
client to communicate with a server even though the cli- 
ent must first authenticate to multiple proxies that re- 
quire different authentication data. The principles of the 

35 present invention permit for such communication with- 
out having to expose authentication data that applies to 
a particular proxy to any proxies that are closer to the 
original server. Therefore, a relatively high degree of 
confidentiality is maintained between the multiple prox- 

40 jes. In addition, the present invention may be imple- 
mented without having to change existing standards, al- 
though the way that those standards are used is unique 
and inventive. 

[0008] In accordance with a first embodiment of the 
45 present invention, the client dispatches a request for a 
service through a first proxy. This first request for service 
may be a standard HTTP request. The first proxy then 
returns an authentication request such as, for example, 
a 407 Proxy Authentication Response in accordance 
50 with HTTP. 

[0009] The client then authenticates the user to the 
first proxy (or first group of proxies that all require the 
same authentication data) by first receiving the authen- 
tication request from the first proxy. The client then re- 
55 trieves authentication data appropriate to authenticate 
to the first proxy. The client then includes that authenti- 
cation data in another request for the service and then 
dispatches that second request. 
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[001 0] The first proxy (or first group of proxies that all 
require the same authentication data) that must be ne- 
gotiated receives the request for service, reads the ap- 
propriate authentication data, and then forwards the re- 
quest for service to the second proxy that must be ne- 
gotiated. This second proxy (or group of proxies that re- 
quire the same authentication data as each other) re- 
quires different authentication data from the first proxy. 
Therefore, the second proxy is not satisfied with the au- 
thentication data in the request and, depending on the 
authentication protocol used, may not even be able to 
read the authentication data in the request. The second 
proxy thus returns an authentication request to the client 
via the first proxy. 

[0011] The client then authenticates the user to the 
second proxy by first receiving the authentication re- 
quest from the second proxy. The client then retrieves 
authentication data appropriate to authenticate to the 
second proxy. The client then includes that authentica- 
tion data for the first and second proxies in yet another 
request for service and dispatches that request for serv- 
ice. 

[001 2] The first proxy receives the request for service, 
reads the appropriate authentication data, and then for- 
wards the request for service to the second proxy that 
must be negotiated. The first proxy also optionally re- 
moves the first authentication data from the request for 
service so that the first authentication data is not ex- 
posed to the second proxy. 

[0013] The second proxy then receives the request for 
service, reads the appropriate authentication data, and 
then forwards the request for service to the server if 
there are no other proxies that must be negotiated. If 
there are further proxies that require yet other authenti- 
cation data, the process of authentication would repeat 
until all proxies have been negotiated. 
[0014] The second embodiment is similar to the first 
embodiment in many respects except for the following 
differences. In the second embodiment, instead of dis- 
patching requests for service through multiple proxies, 
the client makes a connect request directly to the next 
proxy that has not yet be authenticated to. Thus, the cli- 
ent first makes a connect request to the first proxy which 
responds with an authentication request. The client then 
makes a connect request to the second proxy, the con- 
nect request including the authentication data for the 
first proxy. The first proxy receives the connect requests, 
authenticates, and then enters byte forwarding mode 
making the first proxy transparent to the client. The con- 
nect request is forwarded to the second proxy which re- 
sponds with an authentication request. The client then 
dispatches a connect request to the server if there are 
no other proxies that must be negotiated. The connect 
request would include the authentication data for both 
the first and second proxies. If there are further proxies 
to negotiate, connect requests would be made to suc- 
cessive proxies as described herein until all proxies are 
negotiate and a connect request may be made directly 



to the server with the connect request including all au- 
thentication data for all intervening proxies. 
[0015] The first and second embodiments rely on the 
ability to include different authentication data for differ- 

5 ent proxies within a single request. In order to accom- 
plish this, a unique request data structure is described. 
In particular, an HTTP request is described as having 
an associated authentication header such as the 
"WWW-Authenticate Response Header" permitted by 

*0 the HTTP authentication method. The different authen- 
tication data is included under the authentication header 
with each authentication data set for each proxy identi- 
fied by a realm as permitted by the authentication meth- 
od. In this application, a given act is "permitted" or "per- 

15 missible" by a given protocol or method if the given act 
may be performed using the protocol or method without 
violating express standards for the protocol or method. 
It does not mean that the protocol or method describes 
the given act nor that the act would be obvious given 

20 knowledge of the protocol or method. If the digest au- 
thentication method is employed, authentication data is 
not transmitted in the clear, but is encrypted. Thus, only 
the appropriate proxy can read the authentication data 
relevant to that proxy, thus preserving confidentiality be- 

25 tween proxies. 

[0016] Therefore, the principles of the present inven- 
tion allow for a client to communicate with a server even 
if multiple proxies that require different authentication 
data must be traversed in order to establish such corn- 
so munication. In addition, such authentication may be ac- 
complished without exposing authentication data to 
proxies that are closer towards the original server as 
compared to the proxy for which the authentication data 
pertains. In addition, the authentication may be accom- 

35 plished without having to change existing standards. 
[0017] Additional features and advantages of the in- 
vention will be set forth in the description which follows, 
and in part will be obvious from the description, or may 
be learned by the practice of the invention. The features 

40 and advantages of the invention may be realized and 
obtained by means of the instruments and combinations 
particularly pointed out in the appended claims. These 
and other features of the present invention will become 
more fully apparent from the following description and 

45 appended claims, or may be learned by the practice of 
the invention as set forth hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 

so [0018] In order to describe the manner in which the 
above-recited and other advantages and features of the 
invention can be obtained, a more particular description 
of the invention briefly described above will be rendered 
by reference to specific embodiments thereof which are 

55 illustrated in the appended drawings. Understanding 
that these drawings depict only typical embodiments of 
the invention and are not therefore to be considered to 
be limiting of its scope, the invention will be described 
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and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 
[0019] Figure 1 illustrates an exemplary system that 
provides a suitable operating environment for the 
present invention; s 
[0020] Figure 2 illustrates a network configuration in 
which a client must negotiate through two proxies that 
require different authentication data in order to commu- 
nicate with a server; 

[0021] Figure 3 illustrates a network configuration in 10 
which a client must negotiate though more than two 
proxies that require different authentication data in order 
to communicate with a server; 

[0022] Figure 4 illustrates a data flow in the network 
configuration of Figure 2 in which the client dispatches is 
a first request for a service in accordance with a first 
embodiment of the present invention; 
[0023] Figure 5 il lustrates three ordered data flows in- 
volved with the client authenticating to the first proxy in 
accordance with the first embodiment of the present in- 20 
vention; 

[0024] Figure 6 illustrates four ordered data flows in- 
volved with the client authenticating to the second proxy 
in accordance with the first embodiment of the present 
invention; 25 
[0025] Figure 7 illustrates a data flow that completes 
the communication through the first and second proxies 
so that communication is established between the client 
and the server in accordance with the first embodiment 
of the present invention; 30 
[0026] Figure 8 illustrates a flowchart of a method for 
the client to communicate with the server despite having 
to negotiate through multiple proxies that require differ- 
ent authentication data in accordance with the first em- 
bodiment of the present invention; 35 
[0027] Figure 9 illustrates seven ordered data flows 
followed in order for the client to communicate with the 
server despite having to negotiate through multiple 
proxies that require different authentication data in ac- 
cordance with a second embodiment of the present in- 40 
vention; 

[0028] Figure 1 0 illustrates a flowchart of a method for 
the client to communicate with the server in accordance 
with the second embodiment of the present invention; 
and 45 
[0029] Figure 1 1 illustrates a data structure of an HT- 
TP request that may be used when submitting a request 
that includes different authentication data for multiple 
proxies in accordance with the present invention. 

50 

DETAILED DESCRIPTION OF THE INVENTION 

[0030] The present invention extends to methods, 
systems, computer program products and data struc- 
tures for a client to communicate with a server even 55 
though multiple proxies that require different authenti- 
cation data must be traversed to allow such communi- 
cation. Proxies that require different authentication data 



as compared to each other will be referred to herein as 
"heterogenic authentication" proxies. In operation, the 
client first authenticates to a first proxy using authenti- 
cation data appropriate for the first proxy. The client then 
authenticates to a second proxy using different authen- 
tication data that is appropriate for the second proxy. 
This proxy authentication continues through as many 
proxies as necessary until the client is in communication 
with the server. 

[0031 ] The principles of the present invention enables 
a client to communicate through these multiple hetero- 
genic authentication proxies using existing transport 
protocols such as the HyperText Transport Protocol 
(HTTP), existing security protocols such as the Secure 
Socket Layer (SSL) protocol, and existing authentica- 
tion protocols such as the HTTP authentication meth- 
ods. The principles of the present invention may also be 
applied to future developed protocols as well. 
[0032] The embodiments of the present invention 
may comprise a special purpose or general purpose 
computer including various computer hardware, as dis- 
cussed in greater detail below. Embodiments within the 
scope of the present invention also include computer- 
readable media for carrying or having computer-execut- 
able instructions ordata structures stored thereon. Such 
computer-readable media can be any available media 
which can be accessed by a general purpose or special 
purpose computer. By way of example, and not limita- 
tion, such computer-readable media can comprise 
physical storage media such as RAM, ROM, EEPROM, 
CD-ROM or other optical disk storage, magnetic disk 
storage or other magnetic storage devices, or any other 
medium which can be used to carry or store desired pro- 
gram code means in the form of computer-executable 
instructions or data structures and which can be ac- 
cessed by a general purpose or special purpose com- 
puter. 

[0033] When information is transferred or provided 
over a network or another communications connection 
(either hardwired, wireless, or a combination of hard- 
wired or wireless) to a computer, the computer properly 
views the connection as a computer-readable medium. 
Thus, any such connection is properly termed a compu- 
ter-readable medium. Combinations of the above 
should also be included within the scope of computer- 
readable media. Computer-executable instructions 
comprise, for example, instructions and data which 
cause a general purpose computer, special purpose 
computer, or special purpose processing device to per- 
form a certain function or group of functions. 
[0034] Figure 1 and the following discussion are in- 
tended to provide a brief, general description of a suit- 
able computing environment in which the invention may 
be implemented. Although not required, the invention 
will be described in the general context of computer-ex- 
ecutable instructions, such as program modules, being 
executed by computers in network environments. Gen- 
erally, program modules include routines, programs, ob- 
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jects, components, data structures, etc. that perform 
particular tasks or implement particular abstract data 
types. Computer-executable instructions, associated 
data structures, and program modules represent exam- 
ples of the program code means for executing steps of 5 
the methods disclosed herein. The particular sequence 
of such executable instructions or associated data struc- 
tures represent examples of corresponding acts for im- 
plementing the functions described in such steps. 
[0035] Those skilled in the art will appreciate that the 10 
invention may be practiced in network computing envi- 
ronments with many types of computer system config- 
urations, including personal computers, hand-held de- 
vices, multi-processor systems, microprocessor-based 
or programmable consumer electronics, network PCs, is 
minicomputers, mainframe computers, and the like. The 
invention may also be practiced in distributed computing 
environments where tasks are performed by local and 
remote processing devices that are linked (either by 
hardwired links, wireless links, or by a combination of 20 
hardwired or wireless links) through a communications 
network. In a distributed computing environment, pro- 
gram modules may be located in both local and remote 
memory storage devices. 

[0036] With reference to Figure 1 , an exemplary sys- 25 
tern for implementing the invention includes a general 
purpose computing device in the form of a conventional 
computer 1 20, including a processing unit 1 21 , a system 
memory 1 22, and a system bus 1 23 that couples various 
system components including the system memory 1 22 30 
to the processing unit 1 21 . The system bus 1 23 may be 
any of several types of bus structures including a mem- 
ory bus or memory controller, a peripheral bus, and a 
local bus using any of a variety of bus architectures. The 
system memory includes read only memory (ROM) 1 24 35 
and random access memory (RAM) 125. A basic input/ 
output system (BIOS) 126, containing the basic routines 
that help transfer information between elements within 
the computer 120, such as during start-up, may be 
stored in ROM 124. 40 
[0037] The computer 1 20 may also include a magnet- 
ic hard disk drive 1 27 for reading from and writing to a 
magnetic hard disk 139, a magnetic disk drive 128 for 
reading from or writing to a removable magnetic disk 
129, and an optical disk drive 130 for reading from or 4$ 
writing to removable optical disk 1 31 such as a CD-ROM 
or other optical media. The magnetic hard disk drive 
1 27, magnetic disk drive 1 28, and optical disk drive 1 30 
are connected to the system bus 1 23 by a hard disk drive 
interface 132, a magnetic disk drive-interface 133, and 50 
an optical drive interface 134, respectively. The drives 
and their associated computer-readable media provide 
nonvolatile storage of computer-executable instruc- 
tions, data structures, program modules and other data 
for the computer 1 20. Although the exemplary environ- 55 
ment described herein employs a magnetic hard disk 
139, a removable magnetic disk 129 and a removable 
optical disk 131 , other types of computer readable me- 



dia forstoring data can be used, including magnetic cas- 
settes, flash memory cards, digital versatile disks, Ber- 
noulli cartridges, RAMs, ROMs, and the like. 
[0038] Program code means comprising one or more 
program modules may be stored on the hard disk 139, 
magnetic disk 129, optical disk 131 , ROM 124 or RAM 
125, including an operating system 135, one or more 
application programs 136, other program modules 137, 
and program data 1 38. A user may enter commands and 
information into the computer 120 through keyboard 
140, pointing device 142, or other input devices (not 
shown), such as a microphone, joy stick, game pad, sat- 
ellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 121 
through a serial port interface 146 coupled to system 
bus 123. Alternatively, the input devices may be con- 
nected by other interfaces, such as a parallel port, a 
game port or a universal serial bus (USB). A monitor 
1 47 or another display device is also connected to sys- 
tem bus 1 23 via an interface, such as video adapter 1 48. 
In addition to the monitor, personal computers typically 
include other peripheral output devices (not shown), 
such as speakers and printers. 

[0039] The computer 120 may operate in a networked 
environment using logical connections to one or more 
remote computers, such as remote computers 149a and 
149b. Remote computers 149a and 149b may each be 
another personal computer, a server, a router, a network 
PC, a peer device or other common network node, and 
typically include many or all of the elements described 
above relative to the computer 1 20, although only mem- 
ory storage devices 1 50a and 1 50b and their associated 
application programs 136a and 136b have been illus- 
trated in Figure 1. The logical connections depicted in 
Figure 1 include a local area network (LAN) 151 and a 
wide area network (WAN) 152 that are presented here 
by way of example and not limitation. Such networking 
environments are commonplace in office-wide or enter- 
prise-wide computer networks, intranets and the Inter- 
net. 

[0040] When used in a LAN networking environment, 
the computer 120 is connected to the local network 151 
through a network interface or adapter 153. When used 
in a WAN networking environment, the computer 120 
may include a modem 154, a wireless link, or other 
means for establishing communications over the wide 
area network 152, such as the Internet. The modem 
154, which may be internal or external, is connected to 
the system bus 123 via the serial port interface 146. In 
a networked environment, program modules depicted 
relative to the computer 120, or portions thereof, may 
be stored in the remote memory storage device. It will 
be appreciated that the network connections shown are 
exemplary and other means of establishing communi- 
cations over wide area network 152 may be used. 
[0041] The present invention may be used in an en- 
vironment in which a client must authenticate to multiple 
proxies that require different authentication data from 
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the client. Figure 2 illustrates a network configuration 
200 in which the client must authenticate to two proxies 
that reside on different sides of a trust boundary so that 
each proxy is not willing to share authentication data. 
[0042] In the network configuration, in order to com- 5 
municate between client computer system (also called 
"client") 201 and server computer system (also called 
"server") 205, the client must authenticate itself to both 
the first proxy 202 and the second proxy 204 even 
though they both require different authentication data. 10 
Since the first proxy 202 and the second proxy 204 re- 
quire different authentication data, they properly fall 
within the definition of "heterogenic authentication" 
proxies defined above. 

[0043] The first proxy 202 and the second proxy 204 1$ 
are shown divided by a trust boundary 203 to indicate 
that the administrating entity of the first proxy 202 may 
choose to have different authentication data than the ad- 
ministrating entity of the second proxy 204 for security 
reasons. However, it is not required that the first and 20 
second proxies are administered by different entities or 
that they reside in different spheres of trust. 
[0044] When communicating through multiple proxies 
that require the same authentication data (hereinafter 
also called "homogeneous authentication" proxies), 25 
conventional processes allow each of the homogenous 
authentication proxies to read the authentication data 
from a request and forward that request on. The first 
proxy 202 may represent either a single proxy, or multi- 
ple proxies that require the same authentication data, so 
Either way, providing the correct authentication data to 
the first proxy 202 will allow communications through the 
first proxy 202. Similarly, the second proxy 204 may rep- 
resent either a single proxy, or multiple proxies that re- 
quire the same authentication data (though different 35 
from the authentication data required by the first proxy 
202). Either way, providing the correct authentication 
data to the second proxy will allow communications 
through the second proxy 204. 

[0045] The client 201 is illustrated as being a wireless 40 
device in order to describe one potential situation in 
which multiple proxies that require different authentica- 
tion data may need to be traversed in order to access a 
server computer system such as server 205. However, 
the client 201 may be any computer system (such as 45 
the computer 120 described above) that needs to au- 
thenticate to multiple proxies that require different au- 
thentication data in order to communicate with a server. 
If the client 201 is a wireless device, the client 201 may 
first have to authenticate to a proxy (such as proxy 202) so 
that is administered by a wireless carrier. However, the 
client 201 may desire to communicate with a server that 
is protected by a different proxy (such as proxy 204) that 
is managed by a corporate entity. That proxy 204 may 
also require authentication before allowing access to the 55 
server 205. However, the corporate entity and the wire- 
less carrier may not trust each other enough to allow the 
same authentication data to represent the same user. 



Thus, in this circumstance, the first proxy 202 and the 
second proxy 204 would require different authentication 
data. The server 205 may be structured as described 
above for computer 120 although this is also not re- 
quired. 

[0046] Figure 3 illustrates a network configuration 300 
in which the client 201 needs to traverse more than two 
proxies that require different authentication data in order 
to communicate with the server 205. Figure 3 is provided 
to illustrate that the principles of the present invention 
are not limited to network configurations that have two 
proxies that require different authentication data. The 
network configuration includes an arbitrary number 
("N") of heterogenic authentication proxies wherein N is 
two in Figure 2 and more than two in Figure 3. For ex- 
ample, the network configuration includes an Nth proxy 
303 and further trust boundaries 301 and 302. 
[0047] Figures 4 through 7 schematically illustrate a 
data flow in accordance with the present invention as it 
would occur in the network configuration of Figure 2. 
Figures 4 through 7 are similar to Figure 2 except that 
a memory associated with the client 201 is shown for 
clarity. Also, the trust boundary is removed to empha- 
size that it is not necessary that the first proxy 202 and 
second proxy 204 reside in different spheres of trust. 
Also, arrows are provided illustrating data flow. Where 
multiple arrows are shown in a single figure, the arrow- 
head contains a number indicating the order of opera- 
tion within the figure. 

[0048] Although the focus of the description will be on 
the environment shown in Figure 2, there will also be 
some description on how the principles of the present 
invention may apply to the network configuration shown 
in Figure 3 in which there are more than two heterogenic 
authentication proxies. A corresponding flowchart of a 
method for authenticating to multiple heterogenic au- 
thentication proxies is shown in Figure 8. Figure 4 
through 7 will be described with frequent reference to 
Figure 8. 

[0049] Referring to Figures 4 and 8, the client 201 dis- 
patches a first request for a service (act 801 ). This first 
request may be a request in accordance with the Inter- 
net standard HTTP. The client 201 then performs a step 
for authenticating to the first proxy (step 802) which, in 
the embodiment illustrated in Figures 4 through 8, in- 
cludes corresponding act 803, act 804 and act 805. Spe- 
cifically, with reference to Figure 5 and Figure 8, the first 
proxy 202 dispatches a first authentication request, 
which the client 201 ultimately receives (act 803). The 
first authentication request may be, for example, a 407 
Proxy Authentication Response in accordance with HT- 
TP. In response to this authentication request, the client 
201 retrieves first authentication data 402 from memory 
401 , the first authentication data 402 associated with the 
first proxy (act 804). The client 201 then dispatches a 
second request for the service 205, the second request 
including the first authentication data 402 (act 805). The 
client 201 may retrieve the first authentication data 402 
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and dispatch the second request automatically, and 
without requiring user intervention, upon receiving the 
authentication request from the first proxy 202. 
[0050] The client 201 then performs a step for authen- 
ticating to the second proxy (step 806) which, in the em- s 
bodiment illustrated in Figures 4 through 8, includes cor- 
responding act 807, act 808 and act 809. Specifically, 
with reference to Figure 6 and Figure 8, the second 
proxy 204 dispatches a second authentication request, 
which the client 201 ultimately receives via the first proxy 10 
202 (act 807). The first proxy 202 received the second 
request for service, used the first authentication data 
402 to authenticate the user of the client 201 , and then 
forwarded the second request to the second proxy 204. 
Since the second proxy 204 does not recognize the first is 
authentication data 402 and since no other authentica- 
tion data was provided in the second request, the sec- 
ond proxy 204 dispatched the second authentication re- 
quest. The second authentication request may also be 
a 407 Proxy Authentication Response. 20 
[0051] In response to this second authentication re- 
quest, the client 201 retrieves second authentication da- 
ta 403 from memory 401 , the second authentication da- 
ta 403 associated with the second proxy 204 (act 808). 
The client 201 then dispatches a third request for the 25 
service, the third request including the first authentica- 
tion data 402 and the second authentication data 403 
(act 809). The client 201 may retrieve the second au- 
thentication data 403 and dispatch the third request au- 
tomatically, and without requiring user intervention, up- 30 
on receiving the authentication request from the second 
proxy 204. The first proxy 202 then uses the first authen- 
tication data 402 within the third request to authenticate 
the user of the client 201 , and then forwards the third 
request to the second proxy 204. Optionally, the first 35 
proxy 202 may remove the first authentication data so 
that the authentication data is not exposed to the second 
proxy 204. The second proxy 204 then uses the second 
authentication data 403 within the third request to au- 
thenticate the user. 40 
[0052] As illustrated in Figure 7, the second proxy 204 
then forwards the third request to the server 205 to 
thereby establish communication between the client 
201 and server 205 even though multiple heterogenic 
authentication proxies needed to be traversed. If there 4$ 
were more than two heterogenic authentication proxies 
involved as with Figure 3, then the third request would 
be forwarded to the third proxy. The processes de- 
scribed above would be repeated until the request for 
the service included all authentication data required for so 
all of the relevant heterogenic authentication proxies. 
The formulation of the third request to include both the 
first and second authentication data (and other authen- 
tication data if there are more than two heterogenic au- 
thentication proxies) may be accomplished by using ex- ss 
isting protocols to create a unique data structure as de- 
scribed below with reference to Figure 11 . 
[0053] Figure 9 shows a data flow in accordance with 



a second embodiment for establishing a communication 
between the client 201 and the server 205. Figure 1 0 
illustrates a flowchart of a method performed in the en- 
vironment illustrated in Figure 9. The second embodi- 
ment will now be described with frequent reference to 
both Figure 9 and Figure 10. 

[0054] Referring to Figures 9 and 10, the client 201 
first dispatches a connection request to the first proxy 
202 (act 1001). This connection request may be a re- 
quest in accordance with the Internet standard HTTP. 
However, the connection request should be made using 
a protocol that allows for connection requests to be 
made to proxies. One such protocol is the Secure Sock- 
et Layer (SSL) protocol, which may be implemented in 
harmony with HTTP. 

[0055] The client 201 then performs a step for authen- 
ticating to the first proxy (step 1002) which, in the em- 
bodiment illustrated in Figures 9 and 1 0, includes cor- 
responding act 1 003, act 1 004 and act 1 005. Specifical- 
ly, the first proxy 202 dispatches a first authentication 
request, which the client 201 ultimately receives (act 
1003). The first authentication request may be, for ex- 
ample, a 407 Proxy Authentication Response in accord- 
ance with HTTP. In response to this authentication re- 
quest, the client 201 retrieves first authentication data 
402 from memory 401 , the first authentication data 402 
associated with the first proxy (act 1 004). The client 201 
then dispatches a connection request to the second 
proxy 204, the second request including the first authen- 
tication data 402 (act 1 005). The client 201 may retrieve 
the first authentication data 402 and dispatch the con- 
nection request to the second proxy 204 automatically, 
and without requiring user intervention, upon receiving 
the authentication request from the first proxy 202. 
[0056] The client 201 then performs a step for authen- 
ticating to the second proxy (step 1006) which, in the 
embodiment illustrated in Figures 9 and 10, includes 
corresponding act 1007, act 1008 and act 1009. Specif- 
ically, the second proxy 204 dispatches a second au- 
thentication request, which the client 201 ultimately re- 
ceives via the first proxy 202 (act 1007). The first proxy 
202 received the second connection request destined 
for the second proxy 204, used the first authentication 
data 402 to authenticate the user of the client 201 , and 
entered byte forwarding mode thus allowing the first 
proxy 202 to be effectively transparent to the client 201 . 
The connection request is thus properly forwarded to the 
second proxy 204. Since the second proxy 204 does not 
recognize the first authentication data 402, and since no 
other authentication data was provided in the connec- 
tion request, the second proxy 204 dispatched the sec- 
ond authentication request. The second authentication 
request may also be a 407 Proxy Authentication Re- 
sponse. 

[0057] In response to this second authentication re- 
quest, the client 201 retrieves second authentication da- 
ta 403 from memory 401 , the second authentication da- 
ta 403 associated with the second proxy 204 (act 1 008). 
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The client 201 then dispatches a connection request to 
the server 205, the third request including the first au- 
thentication data 402 and the second authentication da- 
ta 403 (act 1009). The client 201 may retrieve the sec- 
ond authentication data 403 and dispatch the connect 5 
request to the server 205 automatically, and without re- 
quiring user intervention, upon receiving the authentica- 
tion request from the second proxy 204. The first proxy 
202 then uses the first authentication data 402 within 
the third connection request to authenticate the user of 10 
the client 201 , and then forwards the third request to the 
second proxy 204. The second proxy 204 then uses the 
second authentication data 403 within the third connec- 
tion request to authenticate to the second proxy 204. 
[0058] As illustrated in Figure 9, the second proxy 204 '5 
then forwards the third connection request to the server 
205 to thereby establish communication between the cli- 
ent 201 and server 205 even though multiple heterogen- 
ic authentication proxies needed to be traversed. If there 
were more than two heterogenic authentication proxies 20 
involved as with Figure 3, then the third connection re- 
quest would be forwarded to the third proxy. The proc- 
esses described above with respect to Figure 9 and Fig- 
ure 10 would be repeated until the connection request 
was dispatched to the server 205 and included all au- 25 
thentication data required by any intervening proxies. 
[0059] The second embodiment requires that a pro- 
tocol be implemented such as SSL that allows for con- 
nections to be made to proxies. The second embodi- 
ment also requires that the client 201 have knowledge 30 
of the address of all intervening proxies between the cli- 
ent 201 and the server 205. The first embodiment has 
no such requirement. 

[0060] In both embodiments, the formulation of the 
third request to include both the first and second authen- 35 
tication data (and other authentication data if there are 
more than two heterogenic authentication proxies) may 
also be accomplished by using existing protocols to cre- 
ate a unique data structure as described below with ref- 
erence to Figure 11 . 40 
[0061] Figure 11 illustrates the relevant components 
of an HTTP request 1100 data structure that may be 
used as the third request for the service (as in Figures 
4 through 8) or as the connection request to the server 
(as in Figures 9 and 10). The HTTP request 1100 in- 
eludes a data field representing proxy authentication da- 
ta 1 1 01 . The authentication data 1 1 01 includes ail of the 
authentication data needed to traverse all heterogenic 
authentication proxies between the client 201 and the 
server 205 as will be described. The HTTP request 1 1 00 so 
also includes other data 1 1 02 permissible in accordance 
with HTTP. This other data 1 1 02 may include, for exam- 
ple, authentication data for use by the server 205. 
[0062] The proxy authentication data 1101 includes a 
data field 1103 that identifies the proxy authentication 55 
data 1 1 01 as being proxy authentication data. In accord- 
ance with the digest authentication method, and as per- 
mitted by HTTP, the proxy authentication header 1103 



may be, for example, the WWW-Authenticate Response 
Header. The proxy authentication data 1101 includes 
authentication data for the first proxy (data field 1104), 
authentication data for the second proxy (data field 
1105) as well as authentication data for other hetero- 
genic authentication proxies, if any (data field 1106). 
[0063] The authentication data for the first proxy in- 
cludes a realm identifier 1 1 07 that identifies that the au- 
thentication data is indeed for the first proxy 202. The 
authentication data for the second proxy also includes 
a realm identifier 1108 that identifies that the authenti- 
cation data is indeed for the second proxy 204. Realm 
identifiers are permitted by the HTTP authentication 
methods although realm identifiers have not conven- 
tionally been used to separate authentication data for 
use by heterogenic authentication proxies. The realm 
identifiers 1107 and 1108 allow the first proxy 202 and 
the second proxy 204 to be able to locate the appropri- 
ate authentication data. 

[0064] The authentication data for the first proxy in- 
cludes the first authentication data 1109 (e.g., the first 
authentication data 402) which may include a first user 
ID 1111 and a first password 1112 for use by the first 
proxy 202. Similarly, the authentication data for the sec- 
ond proxy includes the second authentication data 1110 
(e.g., the second authentication data 403) which may 
include a second user ID 1113 and a second password 
1114 for use by the second proxy 204. 
[0065] The digest authentication method is useful be- 
cause it aliows for data to be defined using realm iden- 
tifiers thus allowing for the appropriate authentication 
data for a given proxy to be properly labeled. Also, it 
allows for proper encryption of the password so that the 
first authentication data 402 is not divulged to the sec- 
ond proxy 204, and so that the second authentication 
data 403 is not divulged to the first proxy 202. Thus, the 
trust boundary 203, if any, is respected in that confiden- 
tial authentication data does not traverse the trust 
boundary. 

[0066] Thus, methods, systems, computer program 
products and data structures are described which allow 
for a client to communicate with a server even though 
multiple proxies that require different authentication da- 
ta are intervening between the client and server. Fur- 
thermore, the principles of the present invention may be 
implemented using existing protocols and without forc- 
ing confidential authentication data to be disclosed be- 
tween the heterogenic authentication proxies. 
[0067] The present invention may be embodied in oth- 
er specific forms without departing from its spirit or es- 
sential characteristics. The described embodiments are 
to be considered in all respects only as illustrative and 
not restrictive. The scope of the invention is, therefore, 
indicated by the appended claims rather than by the 
foregoing description. All changes which come within 
the meaning and range of equivalency of the claims are 
to be embraced within their scope. 
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Claims 

1 . A method of a client computer system transmitting 
a request to a server computer system in a network 
configuration that includes the client computer sys- 5 
tern, the server computer system and a plurality of 
proxy computer systems that the client computer 
system would need to communicate through in or- 
der to communicate with the server computer sys- 
tem, the plurality of proxy computer systems includ- 10 
ing at least a first proxy that requires authentication 
using first authentication data and a second proxy 
that requires authentication using second authenti- 
cation data, the client computer system transmitting 

the request notwithstanding that the first and sec- 15 
ond proxies require different authentication data, 
the method comprising: 

the client computer system dispatching a first 
request for a service; 20 

the client computer system authenticating to 
the first proxy using the first authentication da- 
ta; and 

25 

the client computer system authenticating to 
the second proxy using the second authentica- 
tion data to thereby allow communication be- 
tween the client computer system and the serv- 
er computer system. 30 

2. The method in accordance with claim 1 , wherein: 

the dispatching of a first request comprises: 

35 

the client computer system dispatching the 
first request for the service through the first 
proxy; 

the client computer system receiving a first 40 
authentication request from the first proxy; 
and 

the client computer system retrieving first 
authentication data associated with the 45 
first proxy; 

the authenticating to the first proxy comprises: 

the client computer system dispatching a so 
second request for the service, the second 
request including the first authentication 
data; 

the client computer system receiving a sec- 55 
ond authentication request from the sec- 
ond proxy, the first proxy using the first au- 
thentication data to authenticate the client 



computer system and forwarding the sec- 
ond request for the service to the second 
proxy, the second proxy then receiving the 
second request for the service; and 

the client computer system retrieving sec- 
ond authentication data associated with 
the second proxy; and 

the authenticating to the second proxy compris- 
es: 

the client computer system dispatching a 
third request for the service to the server 
computer system, the third request includ- 
ing the first authentication data and the 
second authentication data, the first proxy 
using the first authentication data to au- 
thenticate the client computer system and 
thereafter forwarding the third request for 
the service to the second proxy, the second 
proxy using the second authentication data 
to authenticate the client computer system 
and thereafter forwarding the third request 
to the server computer system or to a third 
proxy that requires third authentication da- 
ta. 

3. The method in accordance with claim 1 , wherein: 

the dispatching of a first request comprises: 

the client computer system dispatching a 
first connect request as first request to the 
first proxy; 

the client computer system receiving a first 
authentication request from the first proxy; 
and the client computer system retrieving 
first authentication data associated with 
the first proxy; 

the authenticating to the first proxy comprises: 

the client computer system dispatching a 
second connect request as second request 
to the second proxy, the second connect 
request to the second proxy including the 
first authentication data, wherein the first 
proxy uses the first authentication data to 
authenticate the client computer system, 
enters byte forwarding mode, and forwards 
the second connect request to the second 
proxy server; 

the client computer system receiving, via 
the first proxy, a second authentication re- 
quest from the second proxy; and 
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the client computer system retrieving sec- 
ond authentication data associated with 
the second proxy; and 

the authenticating to the second proxy compris- 5 
es: 

the client computer system dispatching a 
third connect request as third request to the 
server computer system or to a third proxy io 
that requires third authentication data, the 
third connect request to the server compu- 
ter system or to the third proxy including the 
first authentication data and the second au- 
thentication data, wherein the second is 
proxy uses the second authentication data 
to a uthent icate t he cli ent comp uter system , 
enters byte forwarding mode, and forward- 
ing the third connect request to the server 
computer system or to the third proxy. 20 

4. The method in accordance with Claim 2 or 3, where- 
in the dispatching of a third request to the server 
computer system or to a third proxy comprises: 

25 

the client computer system including the first 
and second authentication data in the third re- 
quest using an HTTP authentication method. 



5. The method in accordance with Claim 4, wherein 30 
the including of the first and second authentication 
data in the third request using an HTTP authentica- 
tion method comprises: 

identifying the first authentication data using a 35 
first realm associated with the first proxy; and 

identifying the second authentication data us- 
ing a second realm associated with the second 
proxy. 40 

6. The method in accordance with Claim 4, wherein 
the including of the first and second authentication 
data in the third request using an HTTP authentica- 
tion method comprises: 45 

the client computer system including the first 
and second authentication data in a WWW-Au- 
thenticate Response Header associated with 
the digest authentication method. so 

7. The method in accordance with Claim 2 or 3, where- 
in the first and second proxies are administered by 
different entities. 

55 

8. The method in accordance with Claim 7, wherein 
the client computer system comprises a wireless 
device, and the first proxy is administered by a wire- 



less carrier. 

9. The method in accordance with Claim 8, wherein 
the second proxy is administered by a corporate en- 
tity. 

1 0. The method in accordance with Claim 2 or 3, where- 
in the first authentication data comprises a first user 
ID and a first password and/or the second authen- 
tication data comprises a second user ID and a sec- 
ond password. 

11. The method in accordance with Claim 3, wherein 
the dispatching of a first connect request to the first 
proxy, the receiving of a first authentication request 
from the first proxy, the dispatching of a second con- 
nect request to the second proxy, the receiving of a 
second authentication request from the second 
proxy, and the dispatching of a third connect re- 
quest to the server computer system or to a third 
proxy are performed in accordance with the Secure 
Socket Layer (SSL) protocol. 

12. The method in accordance with Claim 2 or 3, where- 
in the dispatching of a first request to the first proxy, 
the receiving of a first authentication request from 
the first proxy, the dispatching of a second request 
to the second proxy, the receiving of a second au- 
thentication requestfrom the second proxy, and the 
dispatching of a third request to the server computer 
system or to a third proxy are performed in accord- 
ance with the HyperText Transport Protocol (HT- 
TP). 

13. The method in accordance with Claim 2, 3 or 12, 
wherein the retrieving of first authentication data 
and the dispatching of a second request to the sec- 
ond proxy are performed automatically, without user 
intervention, upon completion of the receiving of a 
first authentication request from the first proxy. 

14. The method in accordance with Claim 2, 3 or 13, 
wherein the retrieving of second authentication data 
and the dispatching of a third request to the server 
computer system or to a third proxy are performed 
automatically, without user intervention, upon com- 
pletion of the receiving of a second authentication 
request from the second proxy. 

15. The method in accordance with Claim 2, further 
comprising: 

the first proxy removing the first authentication 
data from the third request; and 

the f i rst p roxy f o rward i ng the th ird req u est to the 
second proxy without the first authentication 
data. 
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1 6. The method in accordance with claim 1 , wherein the 
first request for the service represents a connect re- 
quest to the first proxy. 

1 7. A computer-readable medium having computer-ex- 5 
ecutable instructions for performing all the steps of 
the method according to one of the claims 1 to 1 6, 
when run on a computer. 

1 8. The computer-readable medium in accordance with 10 
Claim 17, wherein the computer-readable medium 

is a physical computer-readable medium. 

19. A computer program product comprising a compu- 
ter-readable medium according to claim 1 7 or 1 8. is 

20. A computer-readable medium for use in a network 
configuration that includes a client computer sys- 
tem, a server computer system and a plurality of 
proxy computer systems that the client computer 20 
system would need to communicate through in or- 
der to communicate with the server computer sys- 
tem, the plurality of proxy computer systems includ- 
ing at least a first proxy that requires authentication 
using first authentication data and a second proxy 25 
that requires authentication using second authenti- 
cation data, the computer-readable medium having 
stored thereon a data structure, the data structure 
comprising: 

30 

a first field representing authentication data, 
the first field comprising: 

a second field representing an authentica- 
tion header that identifies the first field as 3s 
containing the authentication data; 

a third field representing authentication da- 
ta for the first proxy; and 

40 

a fourth field representing authentication 
data for the second proxy, 

wherein the third field comprises: 

45 



an eighth field representing the second authen- 
tication data. 

21 . The computer-readable medium in accordance with 
Claim 20 , wherein the fifth field and the seventh field 
each identify a realm in accordance with the digest 
authentication method. 

22. The computer-readable medium in accordance with 
Claim 20 or21 , wherein the first and second authen- 
tication data in the sixth field and the eighth field, 
respectively, are at least partially encrypted. 

23. The computer-readable medium in accordance with 
Claim 20, wherein the fifth field comprises: 

a ninth field representing a first user ID recog- 
nizable by the first proxy as identifying a user 
associated with the client computer system; 
and 

a tenth field representing a first password rec- 
ognizable by the first proxy as identifying a 
password associated with the user; 

wherein the seventh field comprises: 

an eleventh field representing a second user ID 
recognizable by the second proxy as identifying 
the user associated with the client computer 
system; and 

a twelfth field representing a second password 
recognizable by the second proxy as identifying 
a password associated with the user. 

24. The computer-readable medium in accordance with 
Claim 23, wherein the tenth field and the twelfth field 
respectively represent the first and second pass- 
words in encrypted form. 
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a fifth field representing an identifier that iden- 
tifies the third field as containing authentication 
data for the first proxy; and 

a sixth field representing the first authentication so 
data; 

wherein the fourth field comprises: 

a seventh field representing an identifier that ss 
identifies the fourth field as containing authen- 
tication data for the second proxy; and 
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